Packet-based data networks continue to grow in importance, and it is often desirable to monitor network traffic associated with these packet-based networks on an ongoing basis. To meet these monitoring needs, copies of network packets can be forwarded to diagnostic network monitoring tools. Packets are often forwarded using network hubs, test access ports (TAPs), switched port analyzer (SPAN) ports available on network switch systems, and/or other tap devices operating within a network communication system. Network packet brokers (NPBs) can also be used to monitor network traffic and forward filtered traffic to destination monitoring tools.
Testing of network packet communications can also be desirable in network environments. Network testing often involves introduction of test packets into a network environment, collection of the test packets after they have processed by the network environment, and comparison of the test packets to the processed packets. This comparison can provided information about the functioning of the network, such as packet drops, data corruption, packet delays, and/or other potential error conditions or parameters for the network environment.
Certain network systems also include virtual processing environments hosted by one or more host servers. For example, network applications and resources can be made available to network-connected systems as virtualized resources operating within virtualization layers on host servers. In some embodiments, processors or other programmable integrated circuits associated with a server (e.g., server blade) and/or combinations of such servers operate to provide such virtual resources. These hosted virtual processing resources can then be made available to network-connected systems and devices.
Cloud computing services (e.g., Amazon Web Services) can employ a variety of different architectures for provisioning, managing, administering, and orchestrating virtualized computing and storage resources, such as application servers and data storage arrays. For example, cloud service providers often interact with customers to sell/provide them with access to cloud computing resources, where such cloud computing resources include physical servers, data storage arrays, and/or other processing resources. Use of these processing resources, such as through deployment and management of containers, virtual machines, and associated applications within a set of cloud resources is typically provided by controllers within cloud management architectures (e.g., Kubernetes, Mesos, etc.). These cloud management controllers manage, replicate, and schedule virtual resources that can be used to scale up or down processing node deployments requested by customers within allocated sets of cloud resources. Such an architecture, however, tends to deploy processing nodes (e.g., Docker containers, virtual machines, etc.) across a diverse range of geographic locations and related server resources for the purposes of increasing overall service resiliency in the face of geographic-dependent failures.
When network packet testing is desired within virtual processing environments, difficulties can arise with respect to placing testing assets within desired locations within the virtual processing environment. Current cloud service providers (e.g., Amazon Web Services) provide some limited ability to identify regions (e.g., US-east1, US-east2, US-east3, etc.) within which requested cloud resources will be located by the cloud management controller when cloud processing nodes are activated and placed. Limited ability is also provided to identify placement within particular server zones (e.g., availability zones within a given region such as US-east1). However, specific deployment of processing nodes by a customer within particular data centers within these different availability zones (e.g., multiple redundant data centers within each availability zone in US-east1 region) is typically not provided by cloud service providers. Rather, deployment of processing nodes is typically implemented by a cloud service provider based upon resource availability and load balancing algorithms determined by the cloud service provider.
One technique to provision testing for processing nodes is for cloud service customers to place a test agent with each application requested to be deployed within the cloud. For example, where applications are being activated within a cloud, test agents are activated and paired along with them. However, for such paired deployments, the customer pays for the test agent resources regardless of whether tests are being actively run because the resources are allocated by the cloud service provider upon deployment of the paired test agents.
FIG. 1A (Prior Art) is a block diagram of an example embodiment 100 for customer nodes deployed within a cloud environment. For example, a cloud management controller 102 for a cloud service provider receives resource requests 106 from a customer controller 104. These resource requests 106 can include requests to activate processing nodes within the cloud environment. For the example embodiment 100, a cloud region 105 is shown with three server zones 108, 110, and 112. An application (APP) 114 and a paired test agent 116 have been requested and activated in a first server zone (ZONE1) 108. An application (APP) 124 and a paired test agent 126 have been requested and activated in a second server zone (ZONE2) 110. The third server zone (ZONE3) for this example embodiment 100 does not have activated processing nodes for the customer.
In operation, the application 114 communicates with the application 124 with respect to desired network communications and related services for the customer. For example, the application 124 and the application 114 could be part of a video streaming service being provided by the customer (e.g., Netflix). The test agents 116/126 operate to collect test data associated with these network communications and forward this test data through communications 118/128 to the customer controller 104. The customer controller 104 can in turn control the test agents 116/126. However, regardless of whether testing is currently being run or is idle, the customer still pays for the resources used by the paired test agents 116/126 that have been deployed with the applications 114/124, respectively.
In addition to this cost of idle resources, cloud nodes can be moved by the cloud management controller 102 when failures occur and/or can be placed by the cloud management controller 102 in locations that are undesirable for testing purposes. For example, cloud nodes can be moved to fail-over locations in different data centers within server zones 108/110/112 for a particular region 105 or potentially to different server zones.
FIG. 1B (Prior Art) is a block diagram of an example embodiment 150 where the application in the first cloud zone (ZONE1) 108 has failed and has been moved to the third cloud zone (ZONE3) 112. In particular, the original application 114A and paired test agent 116A have failed. After detection of this failure, the cloud management controller 102 has created new application 114B and paired test agent 116B within the third cloud zone 112. In operation, the test agents 116B/126 still collect test data associated with these network communications and forward this test data through communications 118/128 to the customer controller 104. However, the customer controller 104 may not be aware that the test data being received through communications 118 from test agent 116B are from a newly formed resource in the third cloud zone 112 due to the failure of the application 114A.